The move from conventional telephony networks to Internet Protocol (IP) based telecommunication networks is rapidly gaining pace. Multimedia architectures, such as the IP Multimedia Subsystem (IMS) architecture, are being adopted by various telecommunications services to support this movement and provide both mobile and fixed IP-based services to users. IMS is an architecture that uses the IP protocol to provide various services now available from IP-based networks, such as the Internet, to, e.g., various users.
Voice over IP (VoIP) refers to a group of technologies that may be used to transmit voice information over communication networks from a source (calling party) to a destination (called party). Such networks typically include a plurality of VoIP devices (user equipment) that may convert voice and/or video information from its traditional form to a form that is suitable for packet transmission. In other words, the VoIP device encodes, compresses and encapsulates the information into a plurality of data packets that are suitable for being carried by a communication network. Examples of VoIP devices include IP telephones, VoIP network interfaces, certain private branch exchanges (PBXs), personal computers (PCs) running communication applications, certain personal digital assistants (PDAs), network devices providing voice gateway services and so on.
For calls made using VoIP, IMS-based networks typically employ a session protocol to establish sessions (connections) that support the calls. An example of a session protocol that is commonly used is the well-known Session Initiation Protocol (SIP) as described in J. Rosenberg et al., “SIP: Session Initiation Protocol,” Internet Engineering Task Force (IETF) Request For Comments (RFC) 3261. SIP operates at the application layer of the Open Systems Interconnection Reference Model (OSI-RM) and is defined to establish and maintain sessions between users agents (UAs) at user equipment (UE) in a communication network.
In accordance with SIP, when a UA comes on-line, it typically registers with a registration service (registrar) using a SIP REGISTER message. The registrar maintains information about the UA which may include its location, how to reach it and authentication information associated with the UA that may be used to authenticate the UA. Typically, after a UA is registered, the UA is available to receive as well as initiate calls.
In a typical VoIP network, when a call is initiated by a calling party (caller) to a called party, a session is established between the caller and called parties' UAs to support the call. Establishing a session between the parties often involves (a) authenticating both parties and (b) successfully exchanging a sequence of messages between the parties in a predetermined manner. Authentication may involve ensuring the parties have permission to establish the call in the network. The sequence of messages may include (a) a SIP INVITE message issued by the calling party to initiate the session between the calling and called parties, (b) a SIP “200 OK” message issued by the called party to acknowledge the INVITE message and indicate the called party accepts participation in the session, followed by (c) a SIP ACK (acknowledgement) message issued by the calling party to acknowledge the called party's acceptance. After the session is established, a media channel (media stream) may then be established using SIP and associated with the session. The Real-time Transport Protocol (RTP) may be used to transport information in the media channel. RTP is described in H. Schulzrinne et al., “RTP: A Transport Protocol for Real-Time Applications,” IETF RFC 3550.
In some IMS implementations, a Proxy-Call Session/Control Function (P-CSCF) server associated with a UA maintains an awareness of the registration status of the UA in order to determine if sessions established by the UA should be revoked based on the registration status of the UA. For example, if the registration status of a UA changes from “is registered” to “no longer is registered,” the P-CSCF may choose to revoke any outstanding sessions in which the UA is participating. In a typical arrangement, the P-CSCF enters a subscription with a Serving-Call Session/Control Function (S-CSCF) the UA has registered with to be notified of changes in the registration status of the UA. The S-CSCF acts as a registrar that the UA has registered with. If the registration status of the UA changes, the S-CSCF notifies the P-CSCF of the change and the P-CSCF may, in turn, respond accordingly (e.g., terminate any sessions engaged by the UA).
FIG. 1 illustrates a typical exchange of messages between a UA, a P-CSCF and an S-CSCF where the UA registers with the S-CSCF and the P-CSCF subscribes to be notified of changes to the UA's registration status. Referring to FIG. 1, the UA registers with the S-CSCF by generating and forwarding a SIP REGISTER message to the S-CSCF. The message travels to the S-CSCF via the P-CSCF which receives the SIP REGISTER message, notes that the UA is registering with the S-CSCF and forwards the message to the S-CSCF. The S-CSCF receives the message and processes it which may include verifying that the UA has permission to register with the S-CSCF. Assuming that the registration request is accepted by the S-CSCF, the S-CSCF responds with a SIP “200 OK” message.
The “200 OK” message travels to the P-CSCF which notes that the UA has successfully registered with the S-CSCF. At this point, the P-CSCF knows that it needs to establish a subscription with the S-CSCF to monitor the status of the UA's registration. The P-CSCF forwards the “200 OK” message to the UA which receives the “200 OK” message and concludes that it has successfully registered with the S-CSCF. Meanwhile, the P-CSCF generates and forwards a SIP SUBSCRIBE message to the S-CSCF in order to be notified of any changes to the UA's registration status. The S-CSCF receives the subscribe message and processes it including establishing a subscription for the P-CSCF and, generating and forwarding a “200 OK” message to the P-CSCF. The P-CSCF receives the “200 OK” message and concludes that the subscription is “active.” In addition to the “200 OK” message, the S-CSCF also generates and forwards a SIP NOTIFY message to the P-CSCF to notify it of the UA's current registration status. The P-CSCF receives the NOTIFY message and responds to it by generating and forwarding a “200 OK” message to the S-CSCF. The S-CSCF receives the “200 OK” message and concludes that the P-CSCF has successfully received the notification.